좋아요. 아래는 “산정근거(=계산법) → 결과 스펙(표) → 가정/조정 방법 → 참고 경로” 순서로 깔끔하게 정리한 인프라 VM 서버 스펙 산정 문서입니다. (기본 단위는 vCPU, GiB RAM, GB 디스크)

1) 산정 근거(수식·계산법)

1.1 트래픽·동시성(PCU) 추정

• 리틀의 법칙: 동시요청수(또는 시스템 내 평균 사용자수) U = X × (R + Z)
X: 처리량(요청/초), R: 평균 응답시간(초), Z: 평균 씽크타임(초). 웹/성능 분야에서 그대로 적용합니다. WikipediaPerfMatrixDan Slimmon

• 사용자→동시성 변환: 최대동시사용자 U_max ≈ 총사용자 × 활성비율(%).
  (일반 내부업무/포털성 트래픽의 초기 추정치로 **5–15%**를 많이 사용. 필요 시 부하시험으로 보정)

예시(초기치)
운영 200명, 활성 10%, 평균 R=0.3s, Z=5s → U_max=20,
처리량 X = U/(R+Z) = 20 / 5.3 ≈ 3.8 rps (HA 2노드면 대략 노드당 1.9 rps).

1.2 Java WAS 컨테이너 메모리

• JVM은 Heap(Xmx) 외에 Non-heap/스레드/네이티브 메모리가 필요합니다. 운영 현장에서는 컨테이너 메모리 한도 ≈ Xmx × 1.5 정도로 시작하는 경험칙을 많이 씁니다(스레드·TCP 등 비힙 영역 때문에 Xmx보다 더 사용). HomeReddit

• Spring Boot 기본 오버헤드는 수십 MB 수준으로 보고되며, 실제 메모리 프로필은 애플리케이션/라이브러리/로드에 좌우됩니다. HomeAmy's Programming Corner

계산식(초기 제안)
WAS_heap (Xmx) = max(512MiB, f(기능 복잡도, 동시성))
WAS_container_mem = ceil(Xmx × 1.5)
(시작값: 소형 서비스 Xmx=1GiB → 컨테이너 1.5GiB)

1.3 Web(React 정적+리버스 프록시) 컨테이너 메모리

• nginx: 캐시 활성화 안 하면 수십~100MiB대로 매우 작음, 연결당 메모리도 수 KB 수준으로 알려져 있습니다. Server FaultStack Overflow

• Node.js(SSR/간단 BFF 시): 소형 서비스 기준 ~0.5GiB로 시작해 관측 기반으로 보정. Stack OverflowDEV Community

1.4 CPU(웹/프록시 관점) 및 네트워크

• nginx 가이드라인: 대략 암호화 안 된 트래픽 1–2 Gbps당 vCPU 1개 수준의 매우 러프한 시작치. 실제론 응답 크기/SSL/동시성에 좌우되므로 모니터링 필수. blog.nginx.org

• L4/L7 프록시(예: HAProxy)는 코어당 매우 높은 연결 처리량을 보일 수 있으나(튜닝 필요) 실무에선 평균/피크 CPU를 관측해 코어 수를 보정합니다. HAProxy Technologies

1.5 Docker/Compose 및 OS 오버헤드

• 컨테이너 실행 오버헤드는 가상머신 대비 매우 작고, CPU/메모리 효율이 높은 편(일반론). Backblaze

• dockerd/컨테이너 런타임 자체 메모리는 워크로드에 따라 수백 MiB 내외를 잡아두면 안전(보수적 초기치 0.5 GiB 권장). Docker는 컨테이너별 메모리 상한을 --memory 등으로 제한 가능. Docker Documentation

• 리눅스 서버(헤드리스) 기본 OS는 수백 MiB~1 GiB+를 점유. 최소 서버 이미지가 더 작습니다(디스크/메모리 베이스라인 참고). 초기 예약치를 **1 GiB(소형)~2 GiB(여유)**로 둡니다. luisjohnstone.com

1.6 HA 정책과 검증(스테이징) 반영

• 운영 HA(2노드 Active-Active): 용량 분산을 고려하되, 노드 1대 고장 시에도 서비스 유지를 목표로 N+1 관점으로 산정(=노드당 용량을 50% 이상 확보).

• 검증(스테이징): 운영과 동일 스펙 1노드 또는 **운영 1대분(=반용량)**를 권장. (성능/릴리즈 리허설 용도면 운영과 동일 스펙이 가장 안전)

2) 결과 스펙(초기 배치안)

전제: 내부업무 성격(200명/활성 10%·3.8 rps 수준), Web+WAS만 대상, 이미지/DB 등 별도. 실제 반영 전 부하시험으로 보정 권장.

2.1 개발(Dev) – 사용자 20명, 단일 노드(Docker: Web+WAS)

2.2 검증(Stage) – 운영 기준 산정(권장: 운영 1대분)

2.3 운영(Prod) – 사용자 200명, HA 2노드(Active-Active), 각 노드 단일 VM에 Docker(Web+WAS)

튜닝 포인트

• Java: -Xms = Xmx 고정, GC(G1/ZGC)와 -Xss(스레드 스택) 최적화로 메모리 효율 개선 → 관측 도입 후 Xmx 단계 조정. Home

• nginx: 캐시 사용 시 메모리·디스크 별도 예산(캐시 off면 128–256 MiB면 충분한 경우 다수). Server Fault

• Node: SSR·BFF 로직 복잡도/라이브러리에 따라 0.5→1 GiB로 상향 시작 권장. Stack Overflow

3) VM OS 자원 사용량·Docker/Compose 오버헤드 산정

4) 적용·보정 절차(현장 운영용 체크리스트)

1. 초기 배치: 위 스펙으로 배포(컨테이너별 --memory, --cpus 명시) → OOM/CPU 스로틀링 방지. Docker Documentation

2. 관측: JVM Heap(Used/GC), RSS, nginx/Node 메모리, 코어별 CPU, 네트워크 PPS/Throughput을 수집.

3. 보정 규칙

   • WAS: RSS ≈ 1.5×Xmx 근처에서 OOM 경향 있으면 Xmx↑ 또는 스레드/풀 조정. Reddit

   • Web: nginx 캐시 on 시 메모리/디스크 상향. 연결 수↑이면 vCPU·네트워크 스케일. blog.nginx.org

   • 노드 장애 가정 리허설(N+1): 1노드로 트래픽 몰아 부하시험.

5) 빠른 요약(추천 시작 스펙)

• Dev(단일노드): 4 vCPU / 8 GiB RAM / 100 GB 디스크

• Stage(운영 1대분): 4 vCPU / 8–12 GiB RAM / 100–150 GB 디스크

• Prod(HA 2노드, 각 노드): 4 vCPU / 8–12 GiB RAM / 150 GB 디스크

  • 컨테이너 한도(초기): WAS Xmx=1–2 GiB(Dev/Prod) → 컨테이너 1.5–3 GiB, Node 0.5–1 GiB, nginx 0.125–0.25 GiB

  • OS 1 GiB, Docker 0.5 GiB 예약(각 노드)

6) 참고 경로(출처)

• 리틀의 법칙(동시성/처리량/응답시간): 위키피디아, PerfMatrix, Dan Slimmon 블로그(적용 사례). WikipediaPerfMatrixDan Slimmon

• JVM 메모리 구조(Heap/Non-heap): Oracle/Spring 블로그. Oracle DocumentationHome

• Spring Boot 메모리 지표(사례): Spring 블로그/커뮤니티 사례. HomeAmy's Programming CornerReddit

• nginx/Node 컨테이너 메모리 시작치: ServerFault·StackOverflow 토론(현업 경험칙). Server FaultStack Overflow

• Docker 자원 제한/오버헤드 일반론: Docker 공식 문서, Backblaze(컨테이너 vs VM). Docker DocumentationBackblaze

• OS 베이스라인(우분투 최소/디스크·메모리 비교): Ubuntu Server vs Minimal. luisjohnstone.com

• 프록시/웹 CPU 가이드(레퍼런스): NGINX 성능 튜닝 팁, HAProxy 처리량 지표. blog.nginx.orgHAProxy Technologies

필요하면 위 내용을 PDF/PPT 포맷으로도 정리해드릴게요. 테스트 시나리오(활성비율, R/Z, 피크 rps) 수치만 알려주시면, 같은 방식으로 정확한 산정표를 바로 계산해서 반영하겠습니다.

좋습니다. 요청하신 조건(개발 20명, 운영 200명/HA, 단일 노드에 Docker Compose로 Web/WAS 컨테이너 실행)을 기준으로, 산정식(근거) → 통합 스펙 표(개발/검증/운영) → 튜닝·검증 방법 → 참고 경로 순으로 정리했습니다. (기본 단위: vCPU, GiB RAM, GB 디스크)

1) 산정 근거(수식/계산법)

1.1 동시성 및 처리량(초기 추정)

• 리틀의 법칙: 평균 동시 처리량(=시스템 내 평균 사용자수) L = λ × W
  여기서 λ=초당 도착/처리율(rps), W=시스템에 머무는 평균 시간(응답시간+대기)(s). 웹·API 성능 용량 산정에서 표준적으로 사용합니다. WikipediaPerfMatrix

• 사용자→동시성 변환(초기 가정):
  최대 동시 사용자 U_max ≈ 사용자수 × 활성비율(%).
  내부 업무형 앱의 초기값으로 **5–15%**를 가정 후 부하시험으로 보정.

예시(초기치): 운영 200명, 활성 10% → U_max=20. 평균 응답시간 0.3s, 사용자 씽크타임 5s면 처리율 추정 λ ≈ U / (R+Z) = 20 / 5.3 ≈ 3.8 rps (HA 2노드면 노드당 ≈1.9 rps).

1.2 컨테이너별 메모리 한도 산정

• Docker는 컨테이너 메모리 상한을 --memory(혹은 Compose의 memory/deploy.resources.limits)로 강제할 수 있습니다. 최소 설정값 6MB, --memory-swap 등 옵션 조합도 제공됩니다. 운영에서는 각 컨테이너에 메모리 상한을 반드시 명시합니다. Docker Documentation

• Compose 파일에서 플랫폼 의존성이 있으므로, 가장 확실한 방법은 서비스의 mem_limit(v2 스타일) 또는 deploy.resources.limits.memory와 함께 실제 동작을 확인(로컬/배포 환경별)하는 것입니다. 공식 Compose 스펙은 deploy.resources에 한도를 정의합니다. Docker DocumentationGitHub

1.3 OS 및 Docker 런타임 오버헤드

• Ubuntu Server 최소 메모리(클라우드 이미지 기준) 1 GB, ISO 설치 1.5 GB. 실사용은 서비스와 도구에 따라 더 필요할 수 있습니다. Ubuntu Documentation

• Docker 자체 오버헤드는 VM 대비 낮은 편(다수의 실험/연구 결과). 컨테이너 방식이 메모리·CPU 오버헤드가 작다는 비교 연구가 다수 존재합니다. Wiley Online LibraryScienceDirectarXiv
  → 실무 초기치로 OS 1.0 GiB + Docker 데몬/네트워킹 0.3–0.5 GiB를 예약(노드별).

1.4 컨테이너 메모리·CPU 시작점(일반 웹/업무 앱)

• 웹 프록시/정적 서빙(nginx 등): 0.1–0.3 GiB에서 시작(캐시·압축·SSL 설정에 따라 증가).

• BFF/SSR(Node 등): 0.5–1.0 GiB 시작, 관측 기반 보정.

• 업무형 WAS(Java 등): 힙(Xmx) 외 네이티브·스레드·코드 캐시 등 **컨테이너 한도는 보통 1.3–1.6 × Xmx**로 시작(예: Xmx=1 GiB → 컨테이너 1.5 GiB).

• 각 컨테이너에 --cpus(또는 Compose의 cpus)로 코어 상한을 지정해 노이즈/폭주를 방지합니다. Docker Documentation

요약 산식(초기 배치용)

• OS+Docker 예약 M_sys ≈ 1.5 GiB(1.0 + 0.5)

• 서비스 메모리 M_svc = Σ 컨테이너한도

• VM 총 메모리 M_vm = (M_sys + M_svc) × 여유율(1.3~1.5)

• VM vCPU: 최소 4 vCPU 시작(암호화/압축/피크 대비), 관측 후 증감

• 디스크: OS(20–30GB) + 이미지/레이어(30–60GB) + 로그(50GB+) → 100–150GB 시작

2) 통합 스펙(개발/검증/운영)

전제: 단일 노드에 Docker Compose로 Web(프록시/정적/간단 BFF) + WAS 2종 컨테이너 구성. DB, 스토리지, 메시지 브로커 등은 별도라고 가정.

컨테이너 한도(초기 권장)

• web: memory=512MiB(정적/간단 BFF면 512MiB~1GiB), cpus=0.5–1

• was: Xmx=1–2GiB → 컨테이너 memory=1.5–3GiB, cpus=2

• 공통: Compose에서 deploy.resources.limits.memory/cpus 또는 v2 스타일 자원 키 사용(환경에 따라 동작 차이 확인). Docker DocumentationGitHub

2.1 개발(Dev) – 사용자 20명(동시성 낮음), 단일 노드

2.2 검증(Stage) – 운영 기준으로 산정(권장: 운영 1대분)

2.3 운영(Prod) – 사용자 200명, HA 2노드

• 동시성 초기치 U_max ≈ 20(활성 10%) → 노드당 절반 처리 가정.

• N+1: 1노드 장애 시에도 단일 노드가 전체 트래픽 유지를 목표로 한도/스펙을 설정.

메모

• 운영에서 web 0.5→1 GiB, was Xmx 1→2 GiB로 상향한 이유: 피크/SSL/GC·네이티브 오버헤드, 장애 시 단일 노드 운영을 고려한 여유치입니다.

• 실제 목표 rps·응답시간이 더 타이트하면 WAS 메모리/CPU를 우선 증설, 필요 시 web도 상향.

3) Docker/Compose 설정 팁(요약)

• 컨테이너 하드 리밋: docker run --memory=1g --cpus=1 … / Compose에서는 deploy.resources.limits.memory, deploy.resources.limits.cpus 등을 사용(플랫폼마다 지원 차이 있음 → 로컬/개별 배포 환경에서 실제 적용 여부 확인 필수). Docker Documentation+1

• OS/런타임 예약: 노드당 1.5 GiB(Ubuntu 최소 1 GiB + Docker 0.5 GiB) 최소 예약. Ubuntu Documentation

• 컨테이너 vs VM: 컨테이너는 일반적으로 오버헤드가 더 낮음(메모리/CPU) → 동일 하드웨어에서 더 많은 워크로드 수용 가능. 단, 실제 수치는 워크로드에 의존 → 반드시 관측 기반 보정. Wiley Online LibraryScienceDirect

4) 운영 반영·보정 절차

1. 초기 배치: 위 스펙으로 배포하고 컨테이너별 memory/cpus를 반드시 명시. Docker Documentation

2. 관측: rps, 평균/95% 응답시간, 컨테이너 RSS(메모리), GC 지표, 코어별 CPU, 네트워크(pps/throughput) 수집.

3. 보정 규칙(예)

   • WAS RSS가 컨테이너 한도의 80–90%를 자주 넘으면 Xmx ↑ 또는 스레드/풀/GC 튜닝 후 한도 상향.

   • web에서 SSL/압축·대용량 정적파일 비중이 크면 cpus·memory 상향.

   • N+1 리허설: 1노드 다운 후 나머지 1노드가 피크를 처리하는지 부하시험으로 검증.

4. 용량 증설 우선순위: 메모리 → vCPU → 네트워크(앱 특성에 따름).

5) 참고 경로(산정 근거 출처)

• 리틀의 법칙(정의/적용): 위키피디아, PerfMatrix(성능테스트 적용) WikipediaPerfMatrix

• Docker 컨테이너 자원 제한(메모리/CPU 옵션): Docker 공식 문서(엔진) Docker Documentation

• Docker Compose 스펙(리소스 한도 키, 플랫폼 의존성 유의): Docker 공식 Compose 스펙/이슈 문서 Docker DocumentationGitHub

• OS 베이스라인(Ubuntu Server 최소 메모리): Ubuntu 공식 문서(서버 시스템 요구사항) Ubuntu Documentation

• 컨테이너 vs VM 성능 오버헤드(연구/논문): Wiley/Elsevier 등 비교 연구 Wiley Online LibraryScienceDirect

필요하시면 위 내용을 PPT/PDF 템플릿으로 바로 만들어 드릴게요. 운영 목표 rps·응답시간 혹은 실제 부하 패턴(피크 시각/지속시간)이 있으면, 그 수치로 정밀 산정표(자동 계산식 포함)까지 넣어드리겠습니다.

좋습니다. 요청하신 조건(개발 20명, 검증=운영 기준, 운영 200명/HA, 단일 노드 Docker Compose 실행, OS는 RHEL 8 Linux)을 바탕으로, 산정 근거(계산법) → 개발/검증/운영 통합 스펙 표 → Docker/Compose·OS 자원 사용량 → 참고 경로 순으로 정리했습니다.

1) 산정 근거 (계산법)

1.1 사용자 수 → 동시성 추정

• 리틀의 법칙: L = λ × W (시스템 내 평균 사용자 수 = 처리율 × 평균 체류 시간)【turn1search0†source】

• 실무 초기치: 내부업무형 앱에서 활성 동시 사용자 = 총 사용자 × 5~15% 가정.

→ 운영 200명 기준, 활성비율 10% → 동시 사용자 ≈ 20명.
(HA 2노드 → 노드당 평균 10명 처리, 단 1노드 장애 시 전체 20명도 처리 가능해야 함 → N+1 설계)

1.2 VM OS 오버헤드

• RHEL 8 최소 요구 메모리: 1 GB 이상. GUI 없는 서버 환경 기준, 보수적으로 1.5 GB 예약【turn0search3†source】

1.3 Docker/Compose 오버헤드

• Docker 데몬/네트워크 관리: 0.3~0.5 GB 메모리 예약【turn0search12†source】【turn0search4†source】

• 컨테이너 오버헤드: VM 대비 매우 작음, 거의 네이티브에 가까움【turn0search17†source】

1.4 Web/WAS 컨테이너 자원

• Web(nginx/React 정적): 메모리 0.3~0.5 GB, CPU 0.5 vCPU 수준.

• WAS(Java): JVM 힙(Xmx) 외 네이티브 영역 필요. 컨테이너 메모리 한도 = Xmx × 1.5 권장【turn1search9†source】.

  • 개발: Xmx=1 GB → 컨테이너 1.5 GB

  • 운영: Xmx=2 GB → 컨테이너 3 GB

1.5 VM 총 메모리 계산식

ini
Copy code
M_vm = ( M_os + M_docker + Σ컨테이너 한도 ) × 여유율(1.3~1.5)

1.6 디스크 산정

• OS 30 GB + 이미지/레이어 4060 GB + 로그 50 GB = 120150 GB 권장.

2) 개발/검증/운영 통합 스펙 표 (RHEL 8, 단일 노드 Docker Compose)

운영은 HA 2노드 구성, N+1 원칙으로 각 노드가 전체 트래픽을 처리할 수 있어야 함.

3) Docker Compose 및 OS 자원 사용량

• RHEL 8 OS: 1.5 GiB (CLI 기반)【turn0search3†source】

• Docker + Compose 런타임: 0.3~0.5 GiB【turn0search12†source】【turn0search4†source】

• 컨테이너 오버헤드: VM 대비 미미【turn0search17†source】

• Compose 자원 리밋 설정:

  yaml
  Copy code
  services:
    web:
      image: nginx:latest
      deploy:
        resources:
          limits:
            cpus: '1'
            memory: 512M
    was:
      image: openjdk:11
      deploy:
        resources:
          limits:
            cpus: '2'
            memory: 3G
  

  (운영 시 was: 3G, 개발 시 was: 1.5G 등 단계별 조정)

4) 참고 경로

1. 리틀의 법칙 (성능·동시성 계산) – Wikipedia: Little’s Law【turn1search0†source】

2. RHEL 8 최소 요구사항 – Red Hat Enterprise Linux 8 system requirements【turn0search3†source】

3. Docker 메모리 제한 – Docker Docs: Limit a container’s resources【turn1search9†source】

4. 컨테이너 vs VM 오버헤드 – [Elsevier/Wiley 논문 등 비교 연구]【turn0search12†source】【turn0search4†source】【turn0search17†source】

5. Docker Compose 스펙 – Docker Docs: Compose file reference【turn1search1†source】

👉 원하시면 이 내용을 PPT/PDF 산정 근거 문서로 정리해서 드릴 수도 있습니다.
혹시 운영 피크 트래픽(요청/초, 응답시간 목표) 수치가 있다면, 위 계산식으로 좀 더 정밀한 메모리·CPU 산정을 해드릴까요?

아래에 표 + 문서 요약을 먼저 드리고, 맨 아래에 다운로드 파일(엑셀/MD/PDF) 링크도 함께 드렸어요.

RHEL 8 기반 단일 노드(Docker Compose) 리소스 산정

1) 전제 및 산정식(핵심)

• 전제: 개발 20명 / 검증=운영 기준 / 운영 200명(HA 2노드), 단일 VM에서 Docker Compose로 Web(React 정적/프록시/BFF) + WAS(Java) 컨테이너 실행.

• 리틀의 법칙: L = λ × W (동시성≈활성 사용자수) — 처리율·응답시간으로 용량 추정에 적용. Wikipedia

• 컨테이너 메모리 시작점:

  • Web(nginx/BFF): 0.5–1.0 GiB

  • WAS(Java): 컨테이너 메모리 ≈ 1.5 × Xmx (예: Xmx 2 GiB → 3 GiB). Docker는 --memory, Compose는 deploy.resources.limits.memory로 한도 지정. Docker Documentation+1

• OS/Docker 오버헤드(RHEL 8):

  • RHEL 8 설치 최소 RAM 1.5 GiB(x86_64) + 최소 디스크 10 GiB. 운영환경에선 여유를 두고 OS 1.5 GiB + Docker 0.5 GiB를 예약. Red Hat Documentation

  • 컨테이너는 VM 대비 오버헤드가 작고 고밀도 배치에 유리(연구 비교 결과 다수). SVK JournalsDIVA Portal

• VM 총 메모리 계산식(권장)
  M_vm = ( M_os(≈1.5 GiB) + M_docker(≈0.5 GiB) + Σ컨테이너한도 ) × 여유율(1.3~1.5)

2) 통합 스펙 표 (RHEL 8 / 단일 VM / Docker Compose)

개발(Dev) – 사용자 20명

검증(Stage) – 운영 기준 산정(운영 1대분)

운영(Prod) – 사용자 200명, HA 2노드(각 노드), N+1 원칙

실운영에서는 docker stats/APM으로 RSS·GC·CPU·rps 관측해 단계 보정하세요. Docker Documentation

3) Compose 리소스 한도 예시(YAML)

yaml
Copy code
services:
  web:
    image: nginx:latest
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1g    # Dev: 512MiB, Stage/Prod: 1GiB 권장
  was:
    image: eclipse-temurin:17-jre
    environment:
      - JAVA_TOOL_OPTIONS=-Xmx2g   # Dev: -Xmx1g, Prod: -Xmx2g
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 3g     # ≈ 1.5 × Xmx

Compose deploy.resources.limits.memory/cpus 는 공식 스펙입니다(환경/버전에 따라 적용 범위 유의). Docker Documentation

4) 산정 근거(경로)

• Little’s Law(용량·동시성 수식): Wikipedia. Wikipedia

• RHEL 8 시스템 요구사항(설치 최소 RAM/디스크): Red Hat 공식 문서. Red Hat Documentation+1

• Docker 자원 제한 옵션(--memory, --cpus 등): Docker 공식 문서. Docker Documentation

• Docker Compose 리소스 한도 스펙(deploy.resources.limits): Docker 공식 문서. Docker Documentation

• 리소스 관측(docker stats): Docker CLI 공식 문서. Docker Documentation

• 컨테이너 vs VM 오버헤드(연구 비교): 컨테이너가 일반적으로 더 경량/효율적. SVK JournalsDIVA Portal

5) 파일 다운로드

• 엑셀(Dev/Stage/Prod 표)

• 요약 문서(Markdown)

• 요약 문서(PDF)

필요하시면 PPT 템플릿으로도 바로 만들어 드릴게요. 운영 목표 rps/응답시간 수치가 있으면 위 산식에 대입해 정밀 산정표(Xmx·컨테이너 한도·VM 메모리 자동 계산)까지 포함해 드릴 수 있어요.

아래에 **표(요약)**와 환경별 산정근거를 바로 드리고, 맨 아래에 엑셀/MD/PDF 파일도 제공했습니다. (기본 단위: vCPU, GiB, GB)

RHEL 8 + Mendix(Docker Compose) 통합 스펙

통합 표 (개발/검증/운영)

• 리밋은 Compose에서 반드시 명시: deploy.resources.limits.memory/cpus (Compose Deploy 스펙). Docker Documentation

• 관측으로 보정: docker stats로 컨테이너별 CPU, 메모리 사용/리밋, 네트워크 I/O를 실시간 확인해 상향/하향 조정. Docker Documentation+1

환경별 스펙 산정근거

개발(Dev) – 사용자 20명

• OS/Docker 예약: RHEL 8 최소·권장치 참고로 OS 1.5 GiB + Docker 0.5 GiB 예약. Red Hat DocumentationRed Hat Customer Portal

• Mendix 컨테이너: Java 힙(HEAP_SIZE) 초기치 ~1 GiB, 컨테이너 한도는 네이티브/오버헤드 고려 ≈1.5×Xmx → 1.5 GiB. (Mendix HEAP_SIZE 환경변수 사용) Mendix CommunityGitHub

• 여유율 1.5 적용해 8 GiB로 라운딩.

검증(Stage)

• 운영 1대분으로 설정해 릴리스 리허설/성능 리그레션 확인(동일 이미지·리밋). Mendix는 인스턴스당 **메모리(per instance)**를 조정해 수직 스케일 가능. Mendix Documentation

운영(Prod) – 사용자 200명, HA 2노드, N+1

• 활성 동시성 초기 가정(내부업무형) 후 N+1로 1노드 장애 시에도 단일 노드가 전체 트래픽 처리(수직 스케일: 메모리 per instance). Mendix DocumentationMendix

• Mendix 컨테이너: HEAP_SIZE ~2 GiB, 컨테이너 한도 ~3 GiB(≈1.5×Xmx). Dev와 동일하게 Compose 리밋 명시. Mendix Community

• OS/Docker 예약: Dev와 동일 근거(1.5 GiB + 0.5 GiB). Red Hat DocumentationRed Hat Customer Portal

Compose 예시 (메모리/CPU 리밋 + 힙 설정)

yaml
Copy code
version: "3.9"
services:
  mendix:
    image: mendix/mendix-buildpack:latest
    ports: ["8080:80"]
    environment:
      HEAP_SIZE: "2g"                 # Dev: 1g, Prod: 2g
      # 또는: JAVA_TOOL_OPTIONS: "-Xmx2g -XX:MaxRAMPercentage=75"
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 3g                  # ≈ 1.5 × HEAP_SIZE

• Docker 컨테이너 리밋(--memory, --cpus) 및 Compose Deploy 스펙 기준. Docker Documentation+1

• mendix/mendix-buildpack는 UBI8(ubi-minimal) 루트FS를 사용(ubi8 Dockerfile 참조). GitHub

운영 팁(관측·보정)

• docker stats로 **RSS/Limit %**가 80–90%를 자주 넘으면 HEAP_SIZE↑ 또는 리밋↑ 검토. Docker Documentation

• Mendix는 메모리 per instance 조정으로 수직 스케일, 인스턴스 수로 수평 스케일 가능. Mendix Documentation

• 동시성 추정은 리틀의 법칙(L=λ×W)으로 초기치 산정 후 부하시험으로 보정. Mendix Documentation

산정근거에 참조한 사이트(경로)

1. RHEL 8 시스템 요구사항/한계: Red Hat 공식 문서(설치 최소 RAM/디스크, 권장 메모리 표). Red Hat DocumentationRed Hat Customer Portal

2. Docker 컨테이너 자원 제한(--memory, --cpus). Docker Documentation

3. Docker Compose Deploy 스펙(deploy.resources.limits.memory/cpus). Docker Documentation

4. Mendix Buildpack (Docker, UBI8 rootfs) 및 Dockerfile UBI8. GitHub+1

5. Mendix 메모리/스케일(메모리 per instance, HA/멀티 인스턴스). Mendix DocumentationMendix

6. Mendix Docker에서 힙 설정(HEAP_SIZE) 사례. Mendix Community

7. 모니터링: docker stats 명령/런타임 메트릭. Docker Documentation+1

8. (참고) 리틀의 법칙: 초기 동시성/처리량 산정에 사용. Mendix Documentation

파일 다운로드

• 엑셀 (Specs/Rationale/Overhead)

• 문서 (Markdown)

• 문서 (PDF)

필요하시면 위 표·산정근거를 PPT 양식으로도 만들어 드릴게요. 또한 실제 피크 rps/응답시간 목표가 있으면 즉시 반영해 **정밀 산정표(자동 계산식 포함)**로 업데이트해 드립니다.

요청하신 대로 CPU / Memory / Disk 각각의 산정근거를 환경별(개발·검증·운영)로 분리해 표와 문서로 정리했습니다. 아래 요약을 보시고, 맨 아래에서 엑셀/마크다운/PDF 파일을 바로 받으세요.

통합 스펙 요약 (RHEL 8 + Mendix, Docker Compose, 단일 노드)

전제: RHEL 8(헤드리스) / 외부 DB·파일스토리지는 별도 / Compose에서 deploy.resources.limits.memory/cpus 반드시 명시.

CPU 산정근거 (환경별)

• Dev: 개발·테스트 스파이크, GC, 번들 작업을 고려해 최소 2 vCPU, 여유 포함 4 vCPU 권장. Compose에서 mendix 컨테이너 2 vCPU 리밋으로 노이즈·폭주 방지.

• Stage: 운영 1대분과 동일 리밋으로 릴리스 리허설/성능 리그레션 검증 → 4 vCPU 권장.

• Prod(노드당): 200명 중 활성≈10% → 동시성≈20. HA 2노드(Active-Active)이나 N+1 원칙으로 1노드 장애 시 전체 부하 처리 목표. 암호화/압축/GC 오버헤드 고려 4 vCPU 시작, 관측 기반 보정.

Memory 산정근거 (환경별, 산식 포함)

• 기본 예약: OS 1.5 GiB (RHEL 8) + Docker 0.5 GiB

• Mendix(Java) 컨테이너: 컨테이너 메모리 ≈ 1.5 × HEAP_SIZE(Xmx)

Disk 산정근거 (환경별 구성 합)

로그는 애플리케이션/리버스 프록시/시스템 로그 + 로테이션 보존 기간에 따라 증감.

Compose 예시 (CPU/메모리 리밋 + 힙 설정)

yaml
Copy code
version: "3.9"
services:
  mendix:
    image: mendix/mendix-buildpack:latest
    ports: ["8080:80"]
    environment:
      HEAP_SIZE: "2g"                 # Dev: 1g, Stage/Prod: 2g 예시
      # 또는 JAVA_TOOL_OPTIONS: "-Xmx2g -XX:MaxRAMPercentage=75"
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 3g                  # ≈ 1.5 × HEAP_SIZE(Xmx)

산정근거에 참조한 사이트 (URL)

• Little’s Law(동시성/처리율): https://en.wikipedia.org/wiki/Little%27s_law

• RHEL 8 시스템 요구사항(설치 최소 RAM/디스크):
  https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/system-requirements-and-supported-architectures_rhel-installer

• RHEL 8 플랫폼 리밋/권장 참고: https://access.redhat.com/articles/rhel-limits

• Mendix Buildpack (Docker, UBI8 rootfs): https://github.com/mendix/docker-mendix-buildpack

• Mendix Scale Environment(인스턴스당 메모리/인스턴스 수): https://docs.mendix.com/developerportal/deploy/scale-environment/

• Mendix Docker에서 HEAP_SIZE 설정 사례: https://community.mendix.com/link/space/deployment/questions/104696

• Docker 컨테이너 자원 제한(--memory, --cpus): https://docs.docker.com/engine/containers/resource_constraints/

• Docker Compose file reference(deploy.resources.limits): https://docs.docker.com/reference/compose-file/deploy/

• docker stats(관측 지표): https://docs.docker.com/reference/cli/docker/container/stats/

파일 다운로드 (표 + 문서 형태)

• 엑셀 (요약/CPU/메모리/디스크 시트)

• 마크다운 문서

• PDF 요약

추가로, 피크 rps/응답시간 목표, 로그 보존 정책(일수/용량) 같은 운영 수치를 알려주시면 위 표를 즉시 재계산해 더 정밀하게 맞춰드릴게요.

요청하신 “동시 사용자 기준(Dev 20명 동시 + 추가 테스트 여유 / Prod 200명 동시, HA)” 조건으로 CPU·Memory·Disk 각각의 산정근거를 환경별로 정리했고, **표 + 문서(PDF/MD/엑셀)**까지 생성해두었습니다.

통합 스펙 (RHEL 8 + Mendix, Docker Compose, 단일 노드)

Compose에서는 deploy.resources.limits.memory/cpus로 하드 리밋을 반드시 지정하고, 실제 사용량은 docker stats/APM으로 관측해 보정하세요.

CPU 산정근거

• Dev: 20명 동시 + 솔루션 설치/테스트 스파이크를 고려해 6 vCPU 권장. 컨테이너 리밋은 3 vCPU부터 시작, 빌드/테스트성 작업은 가능하면 분리.

• Stage: 운영 1대분과 동일/상향 여유로 8 vCPU. TLS/압축/GC 오버헤드까지 리허설에서 검증.

• Prod(노드당): 200명 동시를 2노드 A/A로 분산(평시 ≈100/노드), N+1으로 1노드 장애 시 단일 노드가 200 동시 처리 목표. 8 vCPU 시작, 관측(rps·CPU%)에 따라 최대 12 vCPU까지 여지.

Memory 산정근거(산식 포함)

• 기본 예약: RHEL 8 OS 1.5 GiB + Docker 0.5 GiB

• Mendix(Java) 컨테이너: 컨테이너 메모리 ≈ 1.5 × HEAP_SIZE(Xmx)

HEAP_SIZE: Dev 2g, Stage 3g, Prod 4g 예시. 컨테이너 리밋은 각각 3g / 4.5g / 6g로 시작(≈1.5×Xmx).

Disk 산정근거

Compose 예시 (CPU/메모리 리밋 + 힙 설정)

yaml
Copy code
version: "3.9"
services:
  mendix:
    image: mendix/mendix-buildpack:latest
    ports: ["8080:80"]
    environment:
      HEAP_SIZE: "4g"                 # Dev: 2g, Stage: 3g, Prod: 4g (예시)
      # 또는: JAVA_TOOL_OPTIONS: "-Xmx4g -XX:MaxRAMPercentage=75"
    deploy:
      resources:
        limits:
          cpus: "6"                    # Dev 3, Stage 4, Prod 4–6 (예시)
          memory: 6g                   # Dev 3g, Stage 4.5g, Prod 6g (≈1.5×HEAP_SIZE)

산정근거 URL

• Little’s Law(동시성/처리율) — https://en.wikipedia.org/wiki/Little%27s_law

• RHEL 8 시스템 요구사항(설치 최소 RAM/디스크) — https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/system-requirements-and-supported-architectures_rhel-installer

• RHEL 8 플랫폼 리밋/권장 — https://access.redhat.com/articles/rhel-limits

• Mendix Buildpack (UBI8 rootfs) — https://github.com/mendix/docker-mendix-buildpack

• Mendix Scale Environment(인스턴스당 메모리/인스턴스 수) — https://docs.mendix.com/developerportal/deploy/scale-environment/

• Mendix Docker HEAP_SIZE 사례 — https://community.mendix.com/link/space/deployment/questions/104696

• Docker 컨테이너 자원 제한 — https://docs.docker.com/engine/containers/resource_constraints/

• Docker Compose deploy resources — https://docs.docker.com/reference/compose-file/deploy/

• docker stats — https://docs.docker.com/reference/cli/docker/container/stats/

파일 다운로드

• 엑셀 (요약/CPU/메모리/디스크)

• 마크다운 문서

• PDF 요약

원하시면 이 수치를 PPT로도 변환해 드릴 수 있어요. 또, 실제 피크 rps/응답시간 목표, 로그 보존 정책을 알려주시면 표 전체를 즉시 재계산해 더 정밀한 스펙으로 업데이트해 드릴게요.

좋아요! 요청하신 조건(Dev 20명 동시 + 추가 테스트 자원, Stage=운영 기준, Prod 200명 동시/HA, RHEL 8 + Docker Compose에서 Mendix 도커 이미지 구동)을 반영해서 CPU / Memory / Disk별 산정근거와 환경별 결과를 한 번에 정리했습니다.
(단위: vCPU, GiB, GB)

1) 통합 스펙 (개발 · 검증 · 운영)

Compose에서는 deploy.resources.limits.memory/cpus로 하드 리밋을 반드시 지정, 실사용량은 docker stats/APM으로 관측해 보정하세요.

2) CPU 산정근거

공통 가정

• Prod 200명 동시 → HA 2노드 Active-Active 시 평시 ≈100명/노드 처리.

• N+1 원칙: 1노드 장애 시 단일 노드가 200명 동시 처리 가능해야 함.

환경별 근거

• Dev: 동시 20명 + 솔루션 설치/테스트 스파이크 반영 → 컨테이너에 3 vCPU부터 시작, 노드 전체는 6 vCPU 권장(빌드/압축/TLS/GC 스파이크 흡수).

• Stage: 운영 1대분 리허설 목적 → 8 vCPU(운영 한 노드와 동일/상향 여유).

• Prod(노드당): 평시 100명/노드, 장애 시 200명/노드까지 → 8 vCPU 시작, 관측(rps·CPU%)에 따라 12 vCPU까지 여지.

3) Memory 산정근거 (수식 포함)

기본 예약(노드 공통)

• RHEL 8 OS(헤드리스): 1.5 GiB

• Docker 엔진/네트워킹: 0.5 GiB

Mendix 컨테이너(자바 런타임)

• 컨테이너 메모리 한도 ≈ 1.5 × HEAP_SIZE(Xmx)
  (힙 외 네이티브/스레드/코드캐시/버퍼 등 오버헤드 흡수용)

환경별 계산

• Dev:
  M_vm = (OS 1.5 + Docker 0.5 + Mendix 3.0) × 여유 1.5 ≈ 7.5 GiB → 12 GiB 라운딩
  (HEAP_SIZE≈2 GiB ⇒ 컨테이너≈3 GiB)

• Stage:
  M_vm = (1.5 + 0.5 + 4.5) × 1.4 ≈ 6.3 GiB → 16–24 GiB (운영 리허설 여유 포함)
  (HEAP_SIZE≈3 GiB ⇒ 컨테이너≈4.5 GiB)

• Prod(노드당):
  M_vm = (1.5 + 0.5 + 6.0) × 1.3 ≈ 6.5 GiB → 16–24 GiB (피크/GC/N+1 여유)
  (HEAP_SIZE≈4 GiB ⇒ 컨테이너≈6 GiB)

운영 적용 후 docker stats로 **RSS/Limit%**가 80–90%를 자주 넘으면 **HEAP_SIZE↑ 또는 컨테이너 리밋↑**로 보정하세요.

4) Disk 산정근거

로그 보존정책(일수/용량)이 크면 로그 파티션/블록디바이스를 별도로 두고 상향하세요.

5) Compose 예시 (CPU/메모리 리밋 + Heap 설정)

yaml
Copy code
version: "3.9"
services:
  mendix:
    image: mendix/mendix-buildpack:latest
    ports: ["8080:80"]
    environment:
      HEAP_SIZE: "4g"                 # Dev: 2g, Stage: 3g, Prod: 4g (예시)
      # 또는 JAVA_TOOL_OPTIONS: "-Xmx4g -XX:MaxRAMPercentage=75"
    deploy:
      resources:
        limits:
          cpus: "6"                   # Dev 3, Stage 4, Prod 4–6 (예시값)
          memory: 6g                  # Dev 3g, Stage 4.5g, Prod 6g (≈1.5×HEAP_SIZE)

6) 산정근거 URL (참고 문서)

• Little’s Law(동시성/처리율 계산 기초):
  https://en.wikipedia.org/wiki/Little%27s_law

• RHEL 8 시스템 요구사항(설치 최소 RAM/디스크):
  https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/system-requirements-and-supported-architectures_rhel-installer

• RHEL 8 플랫폼 리밋/권장:
  https://access.redhat.com/articles/rhel-limits

• Mendix Buildpack (UBI8 rootfs/Docker):
  https://github.com/mendix/docker-mendix-buildpack

• Mendix Scale Environment(인스턴스당 메모리/인스턴스 수 스케일):
  https://docs.mendix.com/developerportal/deploy/scale-environment/

• Mendix Docker에서 HEAP 설정 사례(HEAP_SIZE):
  https://community.mendix.com/link/space/deployment/questions/104696

• Docker 컨테이너 자원 제한(--memory, --cpus):
  https://docs.docker.com/engine/containers/resource_constraints/

• Docker Compose deploy resources(메모리/CPU 리밋):
  https://docs.docker.com/reference/compose-file/deploy/

• docker stats(컨테이너별 실시간 지표):
  https://docs.docker.com/reference/cli/docker/container/stats/

필요하시면 이 내용을 PPT 또는 PDF/엑셀 파일로도 만들어 드릴게요. 운영 목표 rps/응답시간, 로그 보존 정책 수치를 주시면 위 산식에 바로 대입해 더 정밀한 수치로 다시 계산해 드리겠습니다.